1.2.1. Certificate Distribution
When you create the federation trust with either the New-FederationTrust cmdlet or the New
Federation Trust Wizard, the task also copies the certificate used to
all CA and Hub servers in the same Active Directory site. The Cert Distribution Service, which is part of the MS Exchange Service Host service, then distributes the certificate to remote sites as follows:
The
Cert Distribution Service on CA and Hub servers in remote Active
Directory sites monitors Active Directory for changes on the
certificates and tries to retrieve the new certificate immediately on
any change. The service detects new certificates through reading the
certificate thumbprint stored in Active Directory.
The Cert Distribution
Service will first attempt to retrieve the new certificate from a CA or
Hub server within the same Active Directory site.
If
the certificate is not available within the same site, the service will
attempt to retrieve the new certificate from CA or Hub servers in
adjacent sites, such as any that are one hop away. It will try the
sites in the order of least Active Directory cost.
If
retrieving the new certificate from an adjacent site fails, an error is
logged and the service attempts to retrieve the certificate again in
one hour.
1.3. Managing Federation
After you have created your federation trust, you must perform some management and configuration steps.
1.3.1. Configuring DNS for Proof of Ownership
After you have created your federation
trust, you must provide proof of ownership for the domain specified
during the creation of the trust, as well as any other accepted domains
you will be using with federation; we will discuss configuring
additional accepted domains for federation in the Section 1.3.2 section of this article. Providing proof of ownership is accomplished by creating a TXT resource record in your external DNS containing the AppID provided when the federation trust was created. This TXT record is created in the DNS zone for each accepted domain using federation. The following is an example of this text record for Fabrikam:
fabrikam.com IN TXT AppID=000000004001A66A
1.3.2. Configuring Domains for Federation
You specify which authoritative accepted domains in your Exchange organization are configured for federation through the use of the federated
organization identifier; domains are added to the federated
organization identifier, then proof of ownership is established through
creating a TXT record for that domain as outlined in the Section 1.3.1
section of this article. A user must be configured with an e-mail
address defined in the organization identifier for the MFG to recognize
that user and allow that user to use any of the federated delegation features.
The first domain used for federation is set using the Set-FederatedOrganizationIdentifier cmdlet with the –AccountNamespace
parameter; this is the only federated domain that is configured in the
MFG. The URIs (Uniform Resource Identifiers) for additional domains are
configured in the federated organization identifier through the use of
the Manage
Federation Wizard in the EMC or by using the EMS. The following cmdlet
adds the domain fabrikam.co.uk as a federated domain:
Add-FederatedDomain fabrikam.co.uk
Note:
It
is not necessary to configure additional URIs if all users have a
primary or secondary SMTP address for the domain defined in the -AccountNamespace parameter of your federated organization identifier. Whether the domain is their primary SMTP address is unimportant.
Adding an accepted domain using the Manage Federation Wizard in the EMC is shown in Figure 3.
To determine which domains in your organization are federated, you can use the cmdlet Get-FederatedOrganizationIdentifier;
this cmdlet outputs all of the federated domains defined in the
federated organization identifier. You can also view the federated
domains by using the Manage Federation Wizard in the EMC.
1.3.3. Managing Certificates for Federation
The X.509 certificate used for the federation
trust is specified during the creation of the trust and automatically
distributed to all Client Access and Hub Transport servers in your
organization, as outlined in the Certificate Distribution section of
this article. If you need to replace the federation
trust certificate, you accomplish this by installing the new
certificate on an Exchange Server 2010 Client Access or Hub Transport
server (or some other computer with the Exchange Server 2010 management
tools installed) and then configuring the federation
trust from that computer to designate it as the Next Certificate.
Exchange Server 2010 then automatically distributes the certificate to
all Exchange Server 2010 Client Access and Hub Transport servers; when
this distribution has completed, the federation trust is switched to the new certificate by defining it as the Current Certificate.
You can manage the certificates used for federation with the Set-FederationTrust cmdlet; the –Thumbprint parameter configures the specified certificate as the next certificate, as shown in this example:
Set-FederationTrust -Identity MyFederationTrust -Thumbprint
AC00F35CBA8359953F4126E0984B5CCAFA2F4F17
After the next
certificate has been designated, it is automatically distributed to all
Exchange Server 2010 Client Access and Hub Transport servers. You can
use the Test-FederationTrustCertificate cmdlet or the Manage
Federation Wizard to check the distribution status of the certificate.
The distribution process is described in detail in the Section 1.2.1 section of this article.
After the distribution of the next certificate has been verified, you can set it as the current certificate, as shown here:
Set-FederationTrust -PublishFederationCertificate
Alternatively, you can manage the federation certificates using the Manage Federation Wizard as shown in Figure 4.
